home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / winsock / maillist / 94-03.Z / 94-03 / text0115.txt < prev    next >
Encoding:
Text File  |  1994-03-30  |  6.8 KB  |  156 lines

  1. I have two PC's networked with two Unix workstations via ethernet, using 
  2. tcp-ip as the only network protocol. One of the PC's runs QVT/Net via a 
  3. packet driver shim under Win 3.1, the other PC runs QVT/Net on top of 
  4. the Trumpet Winsock under W4W 3.11.  I am getting a decent transfer 
  5. rate (~230 KB/Sec) FTPing between the PC's (client) and workstations 
  6. (server).  However, when I set up one of the PC's (QVT/Net-Trumpet-W4W 
  7. 3.11) as a QVT/Net FTP server for PC-to-PC transfer, the data transfer rate 
  8. slows to a crawl, about 2 KB/Sec.  Any ideas or suggestions will be 
  9. appreciated.
  10.  
  11. David
  12.  
  13.  
  14. -- 
  15. |  David R. McGown       |  dmcgown@access.digex.net  |  (703) 683-1599 (H)  |
  16. |  206 Adams Ave         |  73730.1326@compuserve.com |  (703) 416-3635 (W)  |
  17. |  Alexandria, VA 22301  |                            |                      |
  18. From news@bigblue.oit.unc.edu Wed Mar  9 17:57:54 1994
  19. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  20.           id AA20169; Wed, 9 Mar 1994 13:28:17 -0500
  21. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  22.           id AA19164; Wed, 9 Mar 1994 13:13:44 -0500
  23. Received: from GATEWAY by bigblue with netnews
  24.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  25. To: winsock@sunsite.unc.edu
  26. Date: Wed, 9 Mar 1994 17:57:54 GMT
  27. From: phayes@tamu.edu (Pat Hayes)
  28. Message-Id: <phayes.100.2D7E0E21@tamu.edu>
  29. Organization: Meteorology, TAMU, USA
  30. Sender: ses
  31. References: <1994Mar7.205725.5348@news.stolaf.edu>, <CMC6MH.1Mw@demon.co.uk>, <CMEGJ7.FJu@lotus.com>
  32. Subject: Re: Chameleon Problem ... the future of DOS/Win TCP/IP?
  33.  
  34. Ed wrote:
  35. Various people say they have this or that problem with Chameleon:
  36. ...
  37. ]Check your modem and protocol configs.  I've used Chameleon for a couple
  38. ]years and, while I agree that NewtNews needs major work (hear that, Warren?)
  39. ]the basic product is pretty solid.  I email every day with no problem.
  40. ]...
  41. ]Basically, though, it's a great product.  If you are running MS/Win,
  42. ]there isn't anything out there that comes close.
  43. ]George S. Chapman
  44. ================
  45. ]To me, this use of lower memory is Chameleon's
  46. ]biggest fault. The first 1MB is a critical Windows resource. When it is
  47. ]gone, you start getting "not enough memory to run application" even
  48. ]though you have lots of extended memory and lots of system resources.
  49. ]cedwards1@worldbank.org (Charles Edwards)
  50. ================
  51. Their customer support seems to be buried, perhaps from too much business.
  52. My call was returned within 24 hours, but of course I was away from the
  53. phone. Not much help there. Email queries are not answered.
  54.  
  55. I will not recommend Chameleon to people at my company until the
  56. customer service picture improves dramatically and it is clear that the
  57. software will be upgraded in a timely manner.
  58. Ed Batutis
  59. ================
  60.  
  61. <me>:
  62.  
  63. I think Chameleon has an _OK_ product.  I run PC-X all day and
  64. don't get crashes.  However, a couple of sessions with Eudora or
  65. WinTrumpet or WS_FTP will bring it down every time.  A fix to
  66. one problem I was having with Windows tape backups was to reduce
  67. the size of NFS blocks from 8192 to 1024.  No thanks -- I'll
  68. stick to DOS backups for now.
  69.  
  70. I won't recommend any TSR- or DLL-based TCP/IP stack that 
  71. doesn't lead to a VxD implementation.  See this week's PCWEEK 
  72. for an excellent summary of Frontier's VxD thingy.  Among other
  73. things, a proper VxD stack should use 0K of lower memory, should
  74. be faster than DLLs, has 32-bit code, works in a DOS window, and 
  75. will result in reduced network loads versus DLL-based setups. 
  76. Sounds great!
  77.  
  78. <i'm not involved in any way with Frontier, tho I'll gladly
  79.  serve as a tester for them!>
  80.  
  81.  
  82. --
  83. Pat Hayes, Meteorology, Texas A&M University  *** whoop! ***
  84. phayes@tamu.edu <<--email---U$Mail-->> TAMU,CS,TX,77843-3150
  85.          "...yankee by birth...Aggie by the grace of God..."
  86. From news@bigblue.oit.unc.edu Wed Mar  9 19:50:53 1994
  87. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  88.           id AA09243; Wed, 9 Mar 1994 15:28:19 -0500
  89. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  90.           id AA08336; Wed, 9 Mar 1994 15:10:26 -0500
  91. Received: from GATEWAY by bigblue with netnews
  92.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  93. To: winsock@sunsite.unc.edu
  94. Date: 9 Mar 1994 19:50:53 GMT
  95. From: mhollowa@epo.som.sunysb.edu
  96. Message-Id: <2ll9at$91d@ysics.physics.sunysb.edu>
  97. Organization: SUNY@Stony Brook
  98. Sender: ses
  99. Subject: Re: Mosaic 2.0a1 freezing with 'Sending Command..'
  100.  
  101. In article <pjreid.9.000EDEFD@nbnet.nb.ca> pjreid@nbnet.nb.ca (Patrick and Sharon Reid) writes:
  102. >In article <2la79i$hbl@felix.dircon.co.uk> pmiles@tdc.dircon.co.uk (Peter Miles) writes:
  103. >>I'm using Mosaic v2.0a1 with the Netmanage Chameleon Winsock (v3.11).
  104. >>Every other Winsock application works perfectly suggesting that the Winsock
  105. >>end of things is OK. However, Mosaic often freezes when retrieving html or
  106. >>data with 'sending command...'.
  107.  
  108. >I haven't seen anything like this.  I use Windows Mosaic 2.0a1 with the 
  109. >Trumpet Winsock 1.0 Rev B beta 2.  
  110.  
  111.  
  112. I'm using Trumpet Winsock 1 and odi drivers.  Mosaic 2a2 gives GPF's in 
  113. user.exe whenever I try to access a specific molecular biology database 
  114. site  or try to load large files from a gopher.  It works on other 
  115. occasions.  It makes a fine gopher client, for instance.  I have a very 
  116. hard time believing that it has anything to do with my system or setup 
  117. because all other Windows net apps I've tried work fine.  I've heard from 
  118. one other odi user who seems to be having similar problems. 
  119.  
  120.  
  121.  
  122. From news@bigblue.oit.unc.edu Wed Mar  9 07:25:05 1994
  123. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  124.           id AA14115; Wed, 9 Mar 1994 15:58:20 -0500
  125. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  126.           id AA22592; Wed, 9 Mar 1994 15:57:26 -0500
  127. Received: from GATEWAY by bigblue with netnews
  128.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  129. To: winsock@sunsite.unc.edu
  130. Date: Wed, 09 Mar 94 14:25:05 PDT
  131. From: hoffmann@stolaf.edu
  132. Message-Id: <1994Mar9.203047.29915@news.stolaf.edu>
  133. Organization: St. Olaf College; Northfield, MN  USA
  134. Sender: ses
  135. References: <1994Mar9.122017.27581@worldbank.org>
  136. Subject: Re: Chameleon memory management
  137.  
  138.  
  139. ..
  140. > for lower memory. Chameleon allocates large blocks of memory in the
  141. > first 1MB. When that area is exhausted, Telnet gives the divide by 0
  142. > error. You should try to have as much conventional memory as possible
  143. > available before starting Windows....etc
  144. Charles:
  145. Since this is the case, would it make sense to have an include 
  146. statement in EMM386 for B000-BFFF since I have a VGA monitor? According 
  147. to my books this area is reserved for MDA, CGA, EGA and VGA text.
  148. I, like so many others, keep getting GPF's from MAIL.EXE. Do you see
  149. a connection with GPF's and the way Chameleon handles lower memory?
  150. ------------------------------------------------------------
  151. Norbert Hoffmann
  152. St. Olaf College
  153. Northfield, MN 55057
  154.  
  155.